Amendments to the Specification 

Please replace paragraph [0064] with the following marked-up replacement paragraph: 

— When rows for groups are present in table 400, a pointer, linked list, or similar 
reference (not shown in Fig. 4) may be provided in the group row for identifying the group 
members (and/or for pointing to each member's row in the table). In this manner, duplicated 
rows are avoided when a user is a member of multiple groups. For example, user Ellen is shown 
at elements 332 and 342 of Fig. 3 as being a member of the "Friends" group and the "Garden 
Club" group. Providing a reference from each group to Ellen's individual row 474 allows both 
groups to share this single set of information. Alternatively, the group member information may 
be repeated in each applicable group (e.g., by using a nested structure wherein rows for each 
group member are placed within a collection of rows which are associated with the group), 
without deviating from the scope of the present invention. ~ 

Please replace paragraph [0073] with the following marked-up replacement paragraph: 

— If this user/group is not currently expired, then the projected date when the user or 
group will expire is preferably shown in Fig. 5. In the example, separate projected expiration 
date areas are shown at 522 and 532. As noted above with reference to columns 430 and 450 of 
Fig. 5, when different auto-expiration dates are specified for outbound and inbound messages, 
then the user is preferably auto-expired using the first-occurring one of these dates. For 
example, suppose the auto-expiration date for inbound messages from Mary is February 1, 2003 
and the auto-expiration date for outbound messages to Mary is February 5, 2003. If no 
messages are exchanged with Mary, then an implementation of the present invention preferably 
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auto-expires Mary on February 1st. A single projected expiration date can be presented on 
display 500 to reflect this information (although this has not been shown in the example display 
500). Alternatively, the February 1st auto-expiration for Mary can be disabled by selecting her 
entry as described above and then toggling the "Enable inbound expiration for users" setting to 
OFF. This setting was described above with reference to element 233 of Fig. 2 for global 
defaults. A similar user-specific setting is preferably provided on a display such as that shown in 
Fig. 5, although it has not been illustrated in this example display 500. — 

Please replace paragraph [0086] with the following marked-up replacement paragraph: 

— Block 620 tests whether a sliding date approach is being used. As has been discussed 
with reference to Fig. 4, separate auto-expiration values may be specified for inbound messages 
and for outbound messages, or a single value may be used for both cases. The processing has 
been generally described above, and thus for simplification, Fig. 6 represents use of only a single 
value. Thus, when the test in Block 620 has a negative result, then the auto-expiration value is a 
fixed date, and Block 630 compares that date to the date of the last message. The term "date of 
last message" is used in Fig. 6 as a shorthand reference that should be construed as 
encompassing the "last-sent" value in column 420 and the "last-received" value in column 440. 
And, as stated earlier, the term "date" is meant to include date and/or time, as appropriate. 
Therefore, after making the comparison in Block 630, Block [[640]] 650 tests whether the last 
message is older than the fixed date. If so, then this entry is expired, and control transfers to 
Block 670 where the entry is marked with the expired status (column 460). Otherwise, when 
the test in Block 650 has a negative result, control returns to Block 600 to obtain the next 
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unexpired entry from the table. ~ 
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